With the proliferation of digital media devices such as digital audio tapes (DAT), digital video discs (DVD), digital video cameras and digital still cameras, computer users are demanding an increasing array of hardware and software capabilities to process and use digital media files. A large number of independent hardware vendors (IHVs) and independent software vendors (ISVs) have entered the market to satisfy this demand for increased media functionality. The entry of such a large number of ISVs and IHVs into the market presents many challenges to developers of operating systems and applications with media functionality. For example, the IHVs and ISVs have created a number of inconsistent formats for codecs and other filters. Currently, operating systems and applications have limited capabilities to work with multiple formats that are not widely used.
Filters are software components that are used with media files (e.g., audio, video or still images) to serve as codecs (coders or decoders), to add effects (e.g., color correction, brightness enhancement etc.) or to analyze a file's content (e.g., for extracting metadata such as the number of people in a given image file). Currently, several codec standards (e.g., JPEG, TIFF) are widely used in desk top publishing for formatting image files. Most operating systems, applications and acquisition software support such widely used standards. For example, the acquisition software named Scanner and Camera Wizard in Microsoft® Windows® Me and Microsoft® Windows® XP by Microsoft® Corporation works with scanner and digital camera devices and has the capability to decode and process TIFF files produced by the scanner and digital camera drivers.
However, some manufacturers of hardware such as digital cameras and scanners may prefer to use codecs specially designed to work with their own hardware components. For example, Nikon® Corporation prefers to use a specialized version of TIFF known as TIFF/EP format for coding and decoding digital images. However, TIFF/EP format is not widely used or supported by operating systems or image processing applications. For instance, Windows® XP operating system by Microsoft® Corporation does not support the TIFF/EP format for images. Thus, a Windows® XP desktop user will be unable to decode and view a TIFF/EP image file obtained from a Nikon® camera without installing a separate viewer application. Also, some image processing applications such as Image Viewer by Microsoft® Corporation cannot be extended to support the TIFF/EP standard because they are designed to use a standard TIFF decoder whenever a TIFF type file is presented to the application. Currently, the user may have to add a TIFF/EP codec component to their Windows XP® system and use an application specially designed to work with TIFF/EP images in order to view and enhance TIFF/EP images. Therefore, there is an increased need for operating systems to be more flexible in allowing IHVs, and ISVs to extend the capabilities of existing system processes such as device drivers, acquisition software and other applications by providing their own proprietary filters as add-ins to the system processes. Allowing the IHVs or ISVs to extend the capability of the existing applications or acquisition software will also eliminate the need to create custom applications to work with specialized filters, and instead allow the ISVs and IHVs to concentrate their efforts on providing the best filters as add-ins.
Software developers are usually wary of allowing filters developed by outside entities to be used as add-ins because any errors in the add-in filters can potentially affect the operation of their own software components. Thus, there is a need for systems and methods that adequately ensure the security of the system or the applications using the add-in filters.
Typically, filter components installed on a system either come bundled with an application or are installed to work specifically with certain selected applications. Usually, many of the other applications on the system are not capable of accessing the installed filter's functionality. Thus, there is a need for an open and flexible system architecture that allows for all processes on a system to discover and use add-in filters so that an add-in filter may even be used by unspecified applications, and device drivers.
Additionally, with the demand for increased media functionality, a wide variety of filters with multiple media functionalities are being installed and used on systems. Thus, there is a need for system architecture that is efficient in searching for and enumerating add-in filters installed and available on a system so that an application or a user (through the application) may select the appropriate add-ins as and when it is necessary.
Also, multiple filters installed on a system each may have multiple media functionalities and some of the filters may have functionalities that overlap. In some cases one or more of the filters may be particularly suited for certain type of media processing. A user or a system process may need to discover the functionality of filters before choosing an appropriate filter. One way to accomplish this would be load the filter to memory and then determine its capability. However, this can tie-up system resources and make the filter add-in process tedious and slow. Thus, there is a further need for systems and methods to categorize filters by their features and to search, discover and enumerate the filters by their categorization without loading the filter on to memory.